EC2インスタンスをスケジュールベースで制御する方法を考える

にしざわ

2015.09.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

西澤です。今回は、AWS利用費用のほとんどを占めることになる(ケースの多い)EC2インスタンスの起動時間をスケジュールベースで制御する方法を考えてみたので、いくつかご紹介してみたいと思います。

前提

今回は、機能を紹介することをベースに考えますので、細かい設定手順は省略します。また、OS起動/停止のみの操作で、自動的にサービスを提供できる前提とし、その際のエラーハンドリングは考えないことにします。コスト最適化の為に、検証・開発環境を対象に考えるような想定です。

OS停止/起動に対応して自動でサービスできることが前提
必要となるIAM権限やAWS CLIの操作方法等の細かい説明は省略
詳細な設定手順は省略
それぞれの方法のメリット/デメリットを考えてみる

AWS CLI等を利用したスクリプトで制御

最初に思い付くのは、SDKやAWS CLI等を利用してStartInstances, StopInstancesのAPIをコールすることです。この方法の問題点は、APIを呼び出す実行元サーバが常に起動されていることが前提であること、また、そのスケジュールを管理するジョブスケジューラが必要になることです。

メリット	デメリット
導入が容易実行元はインターネットアクセスさえできれば良い(AWS環境外からでも可)	実行元サーバ自身が常時起動している必要があるジョブスケジューラが必要 AWSの責任範囲外で動作する仕組みに依存する必要がある

目的はコスト最適化なので、バッチサーバは簡単なコマンドを呼び出すだけのmicroインスタンスにしておけば、常時起動にしておいても費用対効果としては問題無いレベルも多いかもしれません。

ジョブスケジューラ

AWSを使う上で、ジョブスケジュールを管理できるマネージドサービスがあると便利なのですが、ひとまずすぐに思い付くのは下記ぐらいかと思います。

Linuxのcron
Windowsのタスクスケジューラ
その他のジョブ管理ソフトウェア

異なる時間に複数台のサーバを制御したい場合には、cronやタスクスケジューラでは限界があると思いますので、何かしらのジョブスケジューラを検討すると良いと思います。下記記事で紹介されていますRundeckも試してみたいところですが、いずれにしてもAWSで管理してもらえないリソースに依存しなければいけないのが課題になります。

ジョブスケジューラ「Rundeck」を試してみる

AWS Data Pipelineを利用

AWSサービスを利用できるところは使い倒し、自分で管理するものは可能な限り減らす、というクラウドらしい使い方を目指すなら、AWS Data Pipelineを検討してみましょう。また、Data Pipelineから呼び出されたEc2Instance Resourceは、スケジュールで設定された時間だけ起動し、ジョブが終了すれば自動的に削除されるので、ジョブ1回につきEC2インスタンスの利用料1h分が課金対象となるイメージとなり、常時起動のバッチサーバを管理する必要が無くなります。

メリット	デメリット
AWSサービスのみで実装でき、管理を委ねることができる AWSマネージメントコンソールから設定できる実行時のみ1h分のEC2料金で利用できる	AWS Data Pipelineインターフェースが独特である為、慣れが必要複数のジョブを管理するには不向き

Data Pipelineは、本来はEMR等の大量データのバッチ処理を組み込むことを想定されているようなので、使い易いインターフェースとは言えないかもしれませんが、設定手順は下記記事に詳しく記載されています。ぜひ試してみてください。

スケジュールベースのAuto Scalingを利用

AWSマネージメントコンソールから設定できない為、あまり知られていない気がするのですが、Auto Scalingにはスケジュールベースで起動台数を制御する機能があります。この機能を利用し、時間契機でDesiredCapacityを1→0→1と変更すれば、サーバの起動/停止と同じような制御が可能です。

メリット	デメリット
AWSサービスのみで実装でき、管理を委ねることができる AutoHealing(min=1,max=1)にすることもできる	Auto Scalingで動作する(起動したらそのままサービスが提供できて、そのまま捨てられる)環境であることが必要 AWSマネージメントコンソールからは設定できない起動済のEC2を組み込むことができない(AMI化すれば可能) 起動の度にAMIから異なるインスタンスIDのサーバが起動される

こうやってまとめていると、あまりメリット無いですね。Auto Scalingの仕様を理解した上で、サービス提供しなくなったら捨てられる状態になっているサーバであれば、検討の価値があると思います。手順は下記をご欄ください。

なぜこれを書きたかったかと言うと、ソンナコトモアロウカトを初めて見た時の衝撃が忘れられないからです。これを考えて、CloudFormationにして、無料で公開してしまうなんて凄すぎると思います。

OpsWorksの時間ベーススケーリングを利用

これもあまり知られていないかもしれませんが、OpsWorksには時間ベースで制御できるインスタンスを作成する機能があります。制約はありますが、起動するAMIを作ってしまえば、AWS Management Consoleを利用して設定することが可能ですので、Auto Scalingを利用する方法と比べるとだいぶ敷居が下がるように思います。

メリット	デメリット
AWSサービスのみで実装でき、管理を委ねることができる AWSマネージメントコンソールから設定できる	起動済のEC2を組み込むことができない(AMI化すれば可能) OpsWorksをサポートしているOSしか使えない(Amazon Linux, Ubuntuのみ)

カスタムAMIでも対応OSであれば、OpsWorksに組み込むことができますので、時間ベースインスタンスとして登録してしまえば、スケジュール設定は他のインターフェースと比較すると信じられないくらい親切な画面で設定が可能です。本来のOpsWorksの用途とは異なりますが、このような機能があることも知っておくと良いと思います。